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Abstract 


The  Canadian  Forces  is  currently  investigating  numerous  technologies  that  support 
data  exchange.  Within  the  Canadian  navy,  the  Global  Command  and  Control  System 
(GCCS)  represents  an  important  system  in  use  on  all  Canadian  Frigates.  The  GCCS  is 
also  used  extensively  throughout  the  United  States  navy  (USN)  and  thus  the  Canadian 
use  also  provides  interoperability  with  the  USN.  Within  the  Canadian  army, 
considerable  resources  and  intellectual  effort  has  been  dedicated  to  the  development  of 
a  semantics  basis,  shared  among  the  NATO  allies,  called  the  Command  and  Control 
Information  Exchange  Data  Model  (C2IEDM).  Since  the  Canadian  forces  also  seek 
interoperability  among  its  own  services  (air,  navy  and  land),  information  exchange 
between  the  GCCS  and  C2IEDM-based  systems  like  the  Land  Forces  Command  and 
Control  Information  System  (LFC2IS)  needs  to  be  explored.  Furthermore,  this 
information  exchange  must  take  place  in  such  a  way  to  minimize  semantic  loss 
between  systems.  This  report  outlines  both  GCCS  and  C2IEDM  and  suggests  a  way 
forward  for  information  exchange  while  maintaining  semantic  integrity.  In  the  short 
term,  it  is  suggested  that  C2IEDM  be  mapped  to  the  messaging  structure  used  by 
GCCS.  In  the  long  term,  it  would  be  advisable  to  have  C2IEDM  as  an  integrated 
ontological  basis  for  the  next  generation  of  the  supporting  environment,  namely  the 
Net  Centric  Enterprise  Services  (NCES). 


Resume 


Les  forces  canadiennes  etudient  presentement  plusieurs  technologies  afin  de  supporter 
1’ echange  de  donnees.  Dans  la  marine  canadienne,  le  Global  Command  and  Control 
System  (GCCS)  constitue  un  important  systeme  en  utilisation  sur  toutes  les  fregates 
canadienne.  GCCS  est  aussi  utilise  de  fagon  extensive  dans  toute  la  marine  americaine 
ce  qui  permet  un  interfonctionnement  systemique  de  facto.  L’armee  canadienne  pour 
sa  part  a  mis  beaucoup  d’ efforts  pour  developper  la  base  semantique  appelee 
Command  and  Control  Information  Exchange  Data  Model  (C2IEDM),  partagee  parmi 
les  allies  de  l’OTAN.  Comme  les  forces  canadiennes  visent  aussi 
F interfonctionnement  entre  ses  propres  services  (air,  mer,  terre),  T echange 
d’  information  entre  les  systemes  respectifs  supportes  par  ces  environnements  doit  etre 
etudie.  De  plus,  cet  echange  d’information  doit  etre  supporte  de  telle  fagon  a 
minimiser  une  perte  semantique  qui  peut  survenir  dans  ce  genre  d’ echange.  Ce  rapport 
decrit  brievement  GCCS  et  C2IEDM  et  suggere  un  mecanisme  pour  supporter 
T echange  d’information  tout  en  maintenant  l’integrite  semantique  de  l’information 
echangee.  II  est  suggere  a  court  terme  qu’une  correspondance  de  donnees  soit  faite 
entre  C2IEDM  et  la  messagerie  structuree  qu’ utilise  GCCS.  A  plus  long  terme,  on 
suggere  que  C2IEDM  soit  integre  totalement  comme  base  semantique  dans 
F architecture  evolutive  de  GCCS,  soit  le  Network-Centric  Enterprise  Services 
(NCES). 
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Executive  summary 


Introduction 

The  Canadian  navy  needs  to  explore  integration  avenues  with  both  the  Unites  States 
(US)  navy  (USN)  and  the  Canadian  army.  Interoperability  with  the  USN  is  a  necessity 
for  the  Canadian  navy,  but  any  Canadian  joint  operations  must  also  allow  navy-army 
information  exchange.  This  document  outlines  the  navy  Global  Command  and  Control 
System  (GCCS)  and  the  army  ontological  basis  called  the  Command  and  Control 
Information  Exchange  Data  Model  (C2IEDM)  and  provides  a  way  forward  for 
combining  data  from  these  two  systems. 

The  Canadian  navy  is  currently  using  GCCS  and  its  supporting  systems  architecture, 
the  US  Defense  Information  Infrastructure  (DII)  Common  Operating  Environment 
(COE),  as  part  of  its  command  and  control  system  onboard  Canadian  Frigates.  The 
formatted  messaging  structure  Over-The-Horizon  Targeting  Gold  (OTH-T-GOLD)  is 
used  by  GCCS  for  message  passing  with  other  GCCS  nodes. 

The  US  Navy  also  uses  the  COE  GCCS.  The  US  Department  of  Defense  is 
researching  the  next  generation  of  the  COE  under  a  project  called  Net  Centric 
Enterprise  Services  (NCES). 

Under  the  Multilateral  Interoperability  Programme  (MIP),  the  Canadian  army  is  one 
member  organisation  researching  and  developing  the  C2IEDM  along  with  the  other 
member  nations.  The  C2IEDM  along  with  its  Information  Exchange  Mechanism 
(IEM)  are  intended  to  be  the  primary  means  to  achieve  systems  interoperability 
between  NATO  nations.  The  Canadian  implementation  of  C2IEDM  is  the  Land  Force 
Command  and  Control  Information  System  (LFC2IS). 


Principal  Results 

The  quickest  way  to  ensure  systems  interoperability  between  GCCS  and  the  LFC2IS  is 
to  build  interfaces  between  the  OTH-T-GOLD  messaging  structure  and  the  C2IEDM. 
An  OTH-T-GOLD-C2IEDM  interface  is  currently  being  built  under  the  auspices  of  the 
Intelligence,  Surveillance,  Target  Acquisition  and  Reconnaissance  (ISTAR) 
Technology  Demonstration  (TD)  led  by  DRDC  Valcartier.  While  this  solution  is 
viable  in  the  short  term,  studies  tend  to  prove  that  this  kind  of  mapping  can  only  hold 
for  a  limited  subset  of  semantic  concepts,  captured  and  shared  by  each  system.  This 
may  still  be  enough  if  the  exchange  of  information  taking  place  supports  the  combined 
army-navy  operational  context. 

In  the  longer  term  and  for  complete  coverage  of  the  domain  semantics,  the  suggestion 
is  to  incorporate  the  C2IEDM  as  a  structured  information  repository  for  the  planned 
NCES.  Indeed,  the  C2IEDM  is  recognized  as  a  very  mature  solution,  approaching  an 
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exhaustive  ontological  basis,  a  recognized  necessity  for  supporting  systems 
interoperability.  This  incorporation  would  allow  the  existing  C2IEDM-based  systems 
to  appear  as  information  providers,  virtually  making  the  NCES  architecture  completely 
interoperable  with  the  NATO  allies  at  the  semantic  level. 


Significance  of  Results 

In  the  short  term,  information  exchange  interface  development  between  GCCS  and 
LFC2IS  (like  demonstrated  in  the  Atlantic  Littoral  ISR  Experiment  -  ALIX)  must  be 
pursued  and  broadened  to  address  the  needs  of  the  various  army-navy  operational 
contexts.  For  the  Canadian  navy,  this  avenue  allows  continued  short-term 
interoperability  with  the  USN  thereby  minimizing  the  cost  of  application  development 
while  maximizing  data  usage. 

The  longer-term  solution  provides  the  Canadian  navy  with  a  very  reasonable  approach 
to  the  exploitation  of  C2IEDM-based  systems  within  a  C2IEDM-enriched  NCES 
vision.  As  such,  NATO  allies  adopting  the  MIP  solution  will  reach  systems 
interoperability  within  the  NCES  vision  as  well. 


Future  Plans 

DRDC  Valcartier  is  currently  working  towards  an  update  of  the  data  mapping  between 
the  OTH-T-GOLD  and  the  C2IEDM.  There  are  also  TD  Projects  at  DRDC  Atlantic 
that  will  examine  the  exchange  and  combining  of  data  from  multiple  sources  and 
platforms.  All  of  these  efforts  are  focused  on  advancing  the  Canadian  Forces  in  the 
area  of  information  sharing  and  exchange. 


Isenor,  Anthony  W.  and  Eric  Dorion.  2005.  The  Use  of  GCCS  in  the  Canadian  Navy 
and  its  Relationship  to  C2IEDM,  DRDC  Atlantic  TM  2004-197,  Defence  R&D  Canada  - 
Atlantic. 
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Introduction 

La  marine  canadienne  se  doit  d’ explorer  les  avenues  d’ integration  tant  avec  la  marine 
americaine  qu’avec  l’armee  de  terre  canadienne.  L’interfonctionnement  avec  la 
marine  americaine  est  une  necessite,  et  toutes  les  operations  jointes  canadiennes 
doivent  aussi  permettre  l’echange  d’ information  entre  les  systemes  des  forces  de  mer 
et  de  terre.  Ce  memorandum  technique  decrit  le  systeme  Global  Command  and 
Control  System  (GCCS)  et  la  base  ontologique  de  l’armee  de  terre  appelee  Command 
and  Control  Information  Exchange  Data  Model  (C2IEDM).  Des  solutions  d’echange 
d’ information  entre  GCCS  et  les  systemes  bases  semantiquement  sur  le  C2IEDM 
seront  ensuite  exposees. 

La  marine  canadienne  utilise  presentement  GCCS  ainsi  que  son  architecture  de 
systemes  «  US  Defense  Information  Infrastructure  Common  Operating  Environment  » 
(DII  COE)  en  tant  que  partie  de  son  systeme  de  commandement  et  controle  sur  ses 
fregates.  La  specification  americaine  de  messagerie  structuree  Over-The-Horizon 
Targeting  Gold  est  utilisee  par  GCCS  pour  transmettre  et  recevoir  des  messages  entre 
noeuds  GCCS. 

La  marine  americaine  utilise  aussi  DII  COE  GCCS.  Le  departement  de  la  defense 
americain  travaille  presentement  a  1’ evolution  du  DII  COE  sous  le  projet  «  Net  Centric 
Enterprise  Services  »  (NCES). 

En  tant  que  membre  du  «  Multilateral  Interoperability  Programme  »  (MIP),  l’armee 
canadienne  developpe  le  C2IEDM  en  compagnie  des  autres  nations  membres.  Le  but 
du  developpement  du  C2IEDM  ainsi  que  son  mecanisme  d’echange  d’ information 
«  IEM  »  est  de  realiser  l’interfonctionnement  semantique  entre  les  nations  de  l’OTAN. 
Le  systeme  de  commandement  et  controle  canadien  base  sur  1’ implementation 
nationale  du  C2IEDM  est  le  Systeme  d’lnformation  de  Commandement  et  Controle 
des  Forces  Terrestres  (SICCFT). 


Resultats  Principaux 

La  fafon  la  plus  rapide  de  realiser  un  interfonctionnement  systemique  entre  GCCS  et  le 
Systeme  d’lnformation  de  Commandement  et  Controle  des  Forces  de  Terre  (SICCFT) 
est  de  construire  des  interfaces  entre  la  structure  de  messagerie  OTH-T-GOLD  et 
C2IEDM.  Un  interface  entre  OTH-T-GOLD  et  C2IEDM  a  ete  construit  et  demontre 
lors  de  T experience  ALIX  en  aout  2004  comme  preuve  de  concept.  Solution  viable  a 
court  terme,  les  etudes  tendent  a  prouver  que  cette  solution  d’ interfonctionnement  se 
limite  generalement  a  un  sous-ensemble  des  concepts  semantiques  compris  dans 
chaque  source  d’ information.  Ceci  peut  toutefois  representer  une  solution  suffisante 
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dans  la  mesure  ou  les  operations  jointes  terre-mer  sont  supportees  par  ce  contexte 
d’  interfonctionnement. 

A  plus  long  terme  et  pour  une  couverture  plus  complete  des  domaines  semantiques,  il 
est  suggere  que  le  C2IEDM  soit  incorpore  dans  le  NCES  en  tant  qu’ entrepot 
d’information  structuree.  En  effet,  le  C2IEDM  est  reconnu  comme  une  solution 
mature,  approchant  les  caracteristiques  d’une  base  ontologique  exhaustive,  une 
condition  requise  pour  supporter  1’ interfonctionnement  systemique.  Cette 
incorporation  permettrait  aux  systemes  bases  sur  C2IEDM  d’agir  en  tant  que 
fournisseur  d’information  directement  dans  le  paradigme  de  NCES.  De  plus,  NCES 
deviendrait  de  facto  interoperable  avec  les  systemes  de  l’OTAN  au  niveau  semantique 
de  1’ information. 


Signification  des  resultats 

A  court  terme,  le  developpement  d’ interfaces  entre  les  systemes  de  la  marine  et  de 
l’armee  de  terre  (tel  que  demontre  a  1’ experience  ALIX)  doit  continuer  et  etre  etendu 
pour  adresser  les  besoins  operationnels  terre-mer  plus  complexe.  Pour  la  marine 
canadienne,  cette  voie  permet  de  maintenir  1’ interfonctionnement  avec  la  marine 
americaine,  minimisant  ainsi  les  couts  de  developpement  tout  en  maximisant 
l’utilisation  de  l’information. 

La  solution  a  long  terme  fournit  a  la  marine  canadienne  une  avenue  d’acces  aux 
systemes  bases  sur  C2IEDM  a  travers  la  vision  NCES.  II  en  est  de  meme  pour  les 
systemes  de  l’OTAN  qui  se  baseront  sur  la  solution  MIP. 


Projets  futurs 

RDDC  Valcartier  mets  a  jour  presentement  l’interface  entre  OTH-T-GOLD  sous  les 
activites  du  projet  Intelligence,  Surveillance,  Target  Acquisition  and  Reconnaissance 
Technology  Demonstrator  (ISTAR  TD).  II  existe  egalement  a  RDDC  Atlantique  des 
projets  de  demonstration  technologique  qui  etudient  l’echange  et  la  combinaison  de 
donnees  provenant  de  multiples  sources  et  plates-formes.  Ces  efforts  on  pour  but 
l’avancement  des  forces  canadiennes  dans  le  domaine  de  l’echange  et  partage  de 
T  information. 
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1.  Introduction 


In  the  past,  system  development  has  been  focused  on  monolithic  systems,  addressing 
specific  functional  requirements.  A  typical  scenario  of  development  involves  the 
identification  of  a  system  or  process  requiring  improvements.  The  defined  functional 
requirements  then  specify  the  modifications  and  design  criteria.  Then,  the 
development  proceeds  based  on  the  requirements,  available  resources,  and  existing 
infrastructure. 

From  a  naval  perspective,  the  traditional  unit  around  which  the  development  took  place 
was  typically  a  naval  platform.  The  development  would  not  necessarily  create  a 
system  to  be  placed  on  a  particular  platform,  but  would  in  some  way  support  the 
activities  of  the  platform.  In  most  cases,  we  may  consider  the  platform1  to  be  a  naval 
ship. 

Many  of  the  developments  to  be  deployed  on  a  ship  would  address  the  command  or 
tactical  needs  of  the  ship.  Across  a  common  class  of  ships,  this  often  results  in  similar 
systems  being  deployed  on  a  single  class.  In  this  way  the  interoperability  of  a 
particular  class  was  realized.  However,  interoperability  between  different  classes  or 
indeed,  different  state  navies,  was  often  not  reached. 

In  the  Canadian  navy,  multiple  ships  working  collectively  for  a  common  goal  are 
termed  a  task  group.  A  task  group  utilizes  the  expertise  and  systems  available  on  all 
the  platforms,  thereby  maximizing  its  collective  effectiveness  to  meet  the  mission  goal. 
However,  groups  of  ships  working  in  partnership  may  also  be  composed  of 
multinational  platforms.  In  either  case,  data  exchange  between  the  platforms  is 
required  to  maintain  a  consistent  view  of  the  operational  environment.  Such  data 
exchange  may  take  many  forms,  such  as  a  transfer  via  voice  messaging,  or  data 
formats  such  as  Over-The-Horizon  Targeting  Gold  (OTH-T-GOLD)  or  Link  11. 

However,  information  exchange  through  the  use  of  message  text  formats  such  as  OTH- 
T-GOLD,  Allied  Data  Publication-3  (Adat-P3)  and  United  States  (US)  Message  Text 
Format  (USMTF)  suffers  from  the  fact  that  the  semantics  conveyed  are  often  not 
complete  or  worse,  are  overlapping.  Therefore  interoperability  requirements,  driven 
by  the  operational  context,  are  not  met.  To  compensate  for  this,  unstructured 
information  transferred  via  voice  communications  or  through  unstructured  message 
exchange  (e.g.,  GENTEXT,  email,  etc.)  may  be  keyed  into  systems  to  complete  the 
information  exchange. 

Furthermore,  formats  such  as  OTH-T-GOLD  and  Link  11  have  been  developed  based 
on  the  data  exchange  requirements  of  the  past.  These  formats  met  the  needs  of  the 
command  and  control  systems  for  which  they  were  built.  However,  the  task  group  or 
coalition  environment  in  present  day  operations  has  different  information  requirements 


1  Platform  may  also  refer  to  an  air  or  subsurface  asset. 
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(IRs)  and  Information  Exchange  Requirements  (IERs).  Multiple  sensors,  on  multiple 
platforms,  exchanging  and  fusing  data,  place  additional  requirements  on  the  transfer. 
Formats,  such  as  OTH-T-GOLD  and  Link  11,  have  not  evolved  to  meet  these  current 
IRs  and  IERs.  The  formats  do  not  cover  all  the  semantics  required  to  conduct  coalition 
or  joint  operations  of  today. 

Numerous  single-system  transfers  use  these  message  text  formats.  Here,  single-system 
refers  to  two  instances  of  the  same  system  operating  in  two  locations.  For  example, 
the  Global  Command  and  Control  System  (GCCS)  in  use  in  the  Canadian  Navy  can 
use  OTH-T-GOLD  to  transfer  point-to-point  data  between  two  GCCS  instances  on  two 
different  ships.  GCCS  was  developed  by  the  US  and  is  used  extensively  in  the 
Canadian  navy.  Its  use  in  Canada  is  an  essential  requirement  for  maintaining  data 
interoperability  with  the  US  navy  (USN). 

Interoperability  between  national  platforms  or  within  a  coalition  has  been  an  active 
area  of  military  research.  In  the  US,  much  of  this  effort  falls  under  the  term,  Net 
Centric  Warfare  (NCW).  In  Canada,  it  has  been  suggested  that  NCW  is  too  restrictive 
and  ill-defined  [1].  For  example,  the  human  or  social  dimension  is  not  apparent  in 
NCW  literature.  Some  Canadian  researchers  are  suggesting  adoption  of  the  term 
Network  Enabled  Operations  (NEOps). 

Some  of  the  research  conducted  under  the  titles  NCW  or  NEOps  is  examining 
architectures  or  models  that  will  support  data  and  information  sharing.  However,  this 
type  of  research  may  be  conducted  along  many  different  implementation  pathways. 
This  raises  the  question  of  whether  or  not  there  will  be  interoperability  between 
pathways.  This  report  will  examine  two  interoperability  pathways  that  are  particularly 
applicable  to  the  Canadian  Forces  (CF). 


1.1  Outline 

The  following  report  provides  very  general  information  on  two  interoperability 
pathways  being  researched  or  used  within  the  CF.  The  first  pathway  suggests  a  means 
to  achieve  systems  interoperability  by  interconnecting  systems  through  specific 
interfaces.  The  second  pathway  describes  the  approach  where  systems  are  designed  to 
use  a  single  shared  semantic  basis. 

Sections  2  and  3  of  this  report  describes  the  building  blocks  constituting  the  subjects  of 
this  study.  Section  2  introduces  the  US  Defense  Information  Infrastructure  (DII) 
Common  Operating  Environment  (COE)  systems  architecture,  developed  by  the  US 
Defense  Information  Systems  Agency  (DISA).  The  COE  is  an  environment  for 
collaborative  software  development  and  execution.  One  system  operating  in  the  COE 
environment  is  the  GCCS,  which  is  also  briefly  described.  GCCS  was  also  developed 
in  the  US,  but  is  used  by  many  allies  including  Canada.  One  method  of  GCCS  data 
communication  is  the  messaging  format  Over-The-Horizon  Targeting  Gold  (OTH-T- 
GOLD).  OTH-T-GOLD  will  also  be  briefly  described. 
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Section  3  introduces  an  interoperability  solution  development  by  the  Multilateral 
Interoperability  Programme  (MIP).  Over  the  last  two  decades,  MIP  has  been  involved 
in  the  specification  and  development  of  the  Command  and  Control  Information 
Exchange  Data  Model  (C2IEDM,  soon  to  be  renamed  to  Joint  Consultation  Command 
and  Control  Information  Exchange  Data  Model,  JC3IEDM,  to  reflect  its  move  toward 
joint  operations).  The  C2IEDM  has  a  long  development  history,  with  the  initial 
concept  dating  back  to  the  mid  1980s  and  the  Generic  Hub  data  model. 

Finally,  the  two  interoperability  approaches  that  serve  to  link  the  GCCS  and  C2IEDM 
will  be  proposed  in  Section  4.  The  approaches  will  be  described  as  either  short  or 
medium-term  solutions  for  the  navy.  These  solutions  will  account  for  the  planned 
development  of  the  COE  by  the  USN  and  for  the  planned  use  of  the  C2IEDM  by  the 
Canadian  army. 
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2.  The  Common  Operating  Environment 


The  Defense  Information  Infrastructure  (DII)  Common  Operating  Environment  (COE) 
was  designed  and  built  in  the  early  1980’ s,  with  the  goal  of  eliminating  incompatibility 
between  US  Department  of  Defense  (DoD)  systems.  The  COE  is  truly  an  environment 
in  which  other  applications  operate.  As  an  environment,  the  COE  provides  the 
necessary  base  services  for  the  higher-level  applications. 

One  system  operating  in  the  COE  environment  is  the  GCCS.  The  GCCS  was 
developed  in  the  US  and  is  used  by  many  allies  including  Canada.  The  GCCS 
provides  military  support  in  areas  such  as  force  mobilization  and  deployment. 

As  with  most  military  packages,  the  COE  and  GCCS  are  evolving  both  in  terms  of 
their  technology  and  the  conceptual  ideas  upon  which  they  are  based.  In  the  next 
generation  of  development,  the  COE  will  evolve  into  a  larger  networked  system,  called 
Net  Centric  Enterprise  Services  (NCES).  NCES  is  important  because  of  the  impact  on 
the  evolution  of  systems  to  the  network  paradigm  and  in  particular  on  the  potential 
impact  on  how  applications  and  databases  interact.  The  next  generation  of  GCCS  is 
the  Joint  Command  and  Control  (JC2)  system.  JC2  will  be  one  application  running 
within  the  NCES. 


2.1  COE  Description 

The  COE  can  be  viewed  from  various  perspectives,  with  each  perspective  resulting  in 
a  slightly  different  description  and  understanding.  Some  view  the  COE  from  the 
perspective  of  functional  areas  [2]  while  other  documentation  [3]  views  it  as  a  multi¬ 
faceted  concept.  The  COE  Integration  and  Runtime  Specification  [3]  (I&RTS) 
describes  the  multi-faceted  concept  where  the  COE  may  be  viewed  as  a  system 
foundation,  a  reference  implementation,  an  implementation  strategy  and  as  an 
architecture. 

In  the  system  foundation  view  [3],  the  COE  should  be  considered  a  foundation  for  the 
construction  of  other  systems.  The  COE  itself  is  not  a  system,  but  rather  is  a  collection 
of  components.  These  components  are  combined  is  different  combinations  to  build 
specific  mission  applications. 

We  may  also  view  the  COE  as  a  reference  implementation  [3].  In  this  view,  we 
consider  the  base  components  that  make  up  the  COE.  These  base  components  are  the 
same  for  each  implementation.  Here  we  are  ignoring  differences  in  the  binary 
executable  files  that  result  from  platform  specifics. 
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The  COE  may  also  be  viewed  as  an  implementation  strategy  [3].  The  COE  strategy  is 
based  on  the  compartmentalization  of  functions  into  well-defined  components  that 
form  the  COE.  The  strategy  also  includes  the  evolution  of  the  component,  where  new 
functionality  may  be  built  into  the  component  in  such  a  way  as  to  move  the  COE 
foundation  forward.  The  strategy  also  considers  legacy  systems  and  how  such  systems 
may  be  integrated  into  the  COE. 

Finally,  the  COE  may  be  viewed  as  an  architecture  [3]  designed  around  the  “plug  and 
play”  concept.  The  software  modules  constructed  for  this  “plug-and-play”  concept  are 
called  segments.  Segments  developed  as  part  of  the  COE  are  referred  to  as 
COE-component  segments.  These  segments  must  adhere  to  well-defined  development 
specifications  as  described  in  the  COE  I&RTS  [3].  These  segments  may  be  considered 
a  functional  software  component  that  typically  addresses  a  specific  functional 
requirement.  However,  these  requirements  are  for  the  general  environment  and  are  not 
related  to  specific  applications. 

These  COE-component  segments  may  also  be  conceptually  bundled  according  to 
general  functionality.  One  bundle  represents  the  kernel  services,  providing  control 
over  COE  administration,  including  utilities  to  manage  and  control  the  COE  base 
system.  In  version  4.7  of  the  COE,  there  are  a  total  of  203  COE-component  segments 
in  14  bundles  [4].  The  14  bundles  are  listed  in  Table  1. 

Individual  mission  requirements  are  typically  addressed  through  multiple  segments.  A 
common  set  of  core  segments  (e.g.,  the  Kernel)  is  combined  with  specific  mission 
segments.  Each  mission  requirement  may  utilize  a  different  set  of  the  COE-component 
segments,  depending  on  the  particular  mission.  For  example,  the  mission  requirement 
addressed  by  the  Global  Command  and  Control  System  -  Maritime  (GCCS-M)  utilizes 
a  particular  set  of  COE-component  segments  that  may  be  different  from  other  mission 
requirements. 

As  well,  an  application  such  as  GCCS-M  will  have  developed  segments  that 
specifically  contribute  to  the  required  functionality  of  the  mission.  These  segments  are 
referred  to  as  mission-application  segments.  The  mission-application  segments  also 
meet  COE  specifications  but  are  not  part  of  the  COE  proper. 
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Table  1.  Version  4. 7  COE-component  segments  are  grouped  into  14  bundles.  The  bundles  cover  the 
functional  requirements  of  the  general  environment.  The  names  of  these  bundles  are  part  of 
the  COE  Taxonomy. 


BUNDLE  ABBREVIATION 

BUNDLE  DESCRIPTION 

ALS 

Alert  Services 

AS 

Administrative  Services 

CMS 

Configuration  Management  Services 

COP 

Common  Operational  Picture 

DAS 

Data  Access  Services 

K 

Kernel 

MCGI  =  MCG&I 

Mapping,  Charting,  Geodesy  and  Imagery 

MMCS 

Multimedia/Collaborative  Services 

MSG 

Messaging 

NMS 

Network  Management  Services 

OA 

Office  Automation 

PS 

Print  Services 

SDS 

Software  Development  Services 

SS 

Security  Services 

2.2  Global  Command  and  Control  System 

The  GCCS  was  designed  to  address  six  mission  areas  for  the  DoD,  namely  operations, 
mobilization,  deployment,  employment,  sustaining  the  mission  and  intelligence.  As 
with  many  other  systems,  the  unique  challenges  associated  with  military  disciplines 
has  resulted  in  GCCS  development  that  is  oriented  towards  the  particular  needs  of  the 
military  community.  For  example,  the  GCCS-Army  (GCCS-A)  [5]  is  a  command  and 
control  system  that  addresses  specific  army  requirements.  GCCS  Top  Secret 
(GCCS-T)  [6]  provides  command  and  control  capabilities  in  a  top-secret  environment. 
Similarly,  GCCS-J  (Joint)  [7],  GCCS-I3  (Integrated  Imagery  and  Intelligence)  and 
GCCS-M  (Maritime)  [8]  provide  specialized  functionality.  These  specialized  systems 
may  collectively  be  considered  the  GCCS  Family  of  Systems  (FoS). 

The  GCCS-M  system  is  of  particular  importance  to  the  Canadian  and  US  navies. 
GCCS-M  supports  navy-based  ashore,  floating  and  mobile/tactical  environments. 
GCCS-M  provides  a  technical  solution  for  the  display  of  information  in  a  common 
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operating  picture  (COP).  GCCS-M  is  reported  to  integrate  data  from  over  80  different 
command  and  control  systems  [9]. 

GCCS-M  is  one  system  within  the  GCCS  FoS.  It  is  important  to  note  that  current  US 
plans  call  for  all  the  systems  to  be  brought  together  under  the  Joint  Command  and 
Control  (JC2)  system.  Current  budgets  indicate  that  the  GCCS-J  will  form  the  initial 
core  of  JC2  [10]. 


2.3  Over-The-Horizon  Targeting  Gold  Message  Format 

As  noted  previously,  GCCS-M  is  currently  installed  on  the  Canadian  frigates.  Part  of 
the  GCCS-M  install  is  the  Tactical  Management  System  (TMS)  [11].  The  TMS 
segment  provides  the  database  management  function  for  the  tactical  data. 

A  planned  fit  will  result  in  the  installation  of  GCCS-M  13,  which  is  an  assortment  of 
selected  functionality  from  GCCS-M  and  GCCS-I3.  This  combines  some  functionality 
from  both  the  maritime  and  intelligence  communities. 

One  functionality  being  included  as  part  of  the  GCCS-M  13  install  is  the  Modernized 
Integrated  Database  (MIDB).  The  MIDB  is  a  repository  for  intelligence  data  and  is 
used  by  American,  Canadian  and  Australian  navies.  Links  exist  between  numerous 
COE-component  segments  and  the  MIDB  mission-application  segments.  Of  particular 
interest,  are  the  mission-application  segments  under  the  GCCS-I3  that  support  the 
manual  fusion  process  and  display  of  multi-source  data.  Some  of  these  mission- 
application  segments  are  now  being  incorporated  into  GCCS-M  13  install. 

GCCS-M  and  GCCS-M  13  use  the  operational  specification  for  OTH-T-GOLD 
formatted  structured  messages.  Under  this  specification,  the  semantics  of  the 
exchangeable  operational  information  is  captured  and  standardized  into  “Message  Text 
Formats”  (MTFs).  In  effect,  a  MTF  is  a  collection  of  semantically  complete 
operational  information.  In  turn,  a  MTF  can  be  broken  into  sets  that  convey  more 
atomically  specific  information  (e.g.,  the  POS  set  specifies  a  position).  Again,  each  set 
can  be  broken  into  fields  that  pertain  specifically  to  that  set  (e.g.,  “Latitude  of  center” 
is  a  field  comprised  in  POS).  If  a  specific  field  takes  values  in  a  ranged  set,  then  the 
OTH-T-GOLD  specification  enumerates  the  range  set. 


2.4  Net  Centric  Enterprise  Services 

There  are  current  plans  to  evolve  the  entire  COE  to  address  interoperability  issues 
associated  with  a  networked  military.  DISA  plans  call  for  the  evolution  of  the  COE 
via  a  program  named  Net  Centric  Enterprise  Services  (NCES)  [12].  In  many  respects, 
NCES  may  be  considered  the  next  generation  of  the  COE. 
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To  understand  the  evolution  of  COE  to  NCES,  one  needs  to  appreciate  the  differences 
in  the  data  handling  methods.  In  the  COE  described  above,  the  data  exist  and  are 
accessible  within  the  COE  architecture.  In  this  environment,  segments  have  direct 
control  over  the  creation  and  manipulation  of  the  data  within  the  various  databases. 

The  data  exist  within  the  environment  and  are  accessible  by  applications  operating 
within  the  environment.  The  data  are  not  necessarily  easily  accessible  by  applications 
external  to  the  COE. 

The  goal  of  NCES  is  to  separate  the  data  and  applications  from  the  environment.  In 
the  NCES,  the  data  conceptually  exist  as  a  service  that  is  independent  of  the 
application.  These  data  services  are  also  a  component  of  the  US  Global  Information 
Grid  (GIG).  NCES  is  intended  to  provide  services  in  support  of  the  GIG. 

In  terms  of  architecture,  NCES  is  constructed  from  Core  Enterprise  Services  (CES) 
and  Communities-of-Interest  (CIO)  (Figure  1).  CES  provides  services  to  the  entire 
network.  For  example,  CES  will  provide  discovery  services  for  the  discovery  of  data 
and  services  over  the  network.  There  will  also  be  services  for  the  mediation  of 
collected  information  and  collaboration  tools.  CIO  will  be  connected  to  the  services 
via  a  communications  backbone.  COI  will  be  organized  around  existing  DoD 
communities  [13]. 

Data  may  exist  in  either  the  CES  or  COI  sections  of  the  architecture  shown  in  Figure  1. 
The  discovery  service  would  provide  the  mechanism  to  locate  and  access  the  required 
data  service  or  application. 
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Figure  1. 


The  NCES  is  based  on  Core  Enterprise  Services  (CES)  providing  essential  services  to 
numerous  communities-of-interest  (COI).  Users  connect  to  the  communication  backbone 
and  thereby  connect  to  the  CES  and  CIOs.  Reproduced  from  [13]. 
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3.  C2IEDM 


The  Command  and  Control  Information  Exchange  Data  Model  (C2IEDM)  [14]  is  a 
development  that  originated  in  the  Multilateral  Interoperability  Program  (MIP)  [15]. 
MIP  is  not  a  formal  program,  but  rather  is  a  voluntary  activity  of  supporting  nations. 
The  aim  of  the  MIP  is  “to  achieve  international  interoperability  of  Command  and 
Control  Information  Systems  (C2IS)  at  all  levels  from  corps  to  battalion ,  or  the  lowest 
appropriate  level ,  in  order  to  support  multinational  (including  NATO2),  combined  and 
joint  operations  and  the  advancement  of  digitization  in  the  international  arena ”  [16]. 

MIP  (and  the  former  Army  Tactical  Command  and  Control  Information  System 
(ATCCIS)  programme)  have  been  involved  in  the  specification  and  development  of  the 
C2IEDM  for  over  two  decades,  with  the  initial  concept  dating  back  to  the  mid  1980s 
and  the  Generic  Hub  data  model.  C2IEDM  will  soon  be  renamed  to  the  Joint 
Consultation  Command  and  Control  Information  Exchange  Data  Model  (JC3IEDM), 
to  reflect  its  move  toward  joint  operations. 

The  MIP  solution  consists  of  two  main  functional  components:  1)  the  C2IEDM,  and 
2)  the  Information  Exchange  Mechanism  (IEM).  Both  will  be  briefly  described. 


3.1  C2IEDM  Description 

The  MIP  committee  approved  the  C2IEDM  Edition  6  in  November  2003.  The  data 
model  specification  and  supporting  documentation  was  made  available  on  the  MIP 
web  site  [15]  in  the  spring  of  2004.  The  C2IEDM  is  the  natural  evolution  of  the 
LC2IEDM  (prefix  L  indicates  Land),  with  additional  tables  for  navy  and  air  force 
specific  information.  There  has  also  been  additional  work  on  clarifying  some  table 
descriptions  and  content  to  make  a  more  generic  structure. 

When  considering  the  C2IEDM,  we  must  first  recognize  several  important  terms  that 
relate  the  C2IEDM  to  the  larger  system.  The  C2IEDM  is  not  a  system  but  rather  a 
structured  set  of  semantic  concepts  and  their  relationships  that  pertain  to  an  ontology 
definition  (a  semantic  basis).  The  C2IEDM  as  a  data  model  serves  as  the  means  to 
capture  the  military  ontology  necessary  to  conduct  coalition  operations.  It  consists  of 
about  200  tables  and  supporting  relationships.  The  main  model  concepts  deal  with 
objects  that  exist  at  described  locations.  The  model  allows  the  objects  to  have 
described  capabilities,  which  leads  to  the  objects  conducting  certain  actions  on  targets. 
The  objects  may  also  operate  in  a  certain  context  which  may  be  defined  by  the 
reporting  of  associated  objects,  capabilities,  actions,  etc.  or  through  the  actions  of  the 
objects  relative  to  described  rules-of-engagement. 


2  NATO  -  North  Atlantic  Treaty  Organization 
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3.2  Exchange  Description 


The  second  component  of  the  MIP  solution  is  the  Information  Exchange  Mechanism. 
The  IEM  accounts  for  two  types  of  exchange:  The  Message  Exchange  Mechanism 
(MEM)  and  the  Data  Exchange  Mechanism  (DEM). 


3.2.1  The  Message  Exchange  Mechanism 

The  Message  Exchange  Mechanism  (MEM)  [17]  uses  the  Extended  Simple  Mail 
Transfer  Protocol  (ESMTP)  to  exchange  Adat-P3  formatted  messages.  MIP 
maintained  a  set  of  these  messages  that  capture  key  information  within  the  C2IEDM. 
Although  the  MEM  was  meant  to  convey  semantic  information  between  MIP- 
compliant  nodes  it  proved  to  be  flawed  for  a  number  of  reasons.  First,  the  semantic 
integrity  of  these  messages  is  very  hard  to  ensure.  This  is  because  the  Adat-P3  (as  well 
as  other  message  text  formats  like  OTH-T-GOLD  and  USMTF)  is  merely  a  collection 
of  military  terms  with  no  definitions  or  relationships.  Second,  the  semantics  of  a 
message  is  given  through  the  message  structure  (e.g.,  Situation  Report,  etc.)  and  its 
composition.  The  attributes  that  compose  the  messages  often  violate  the  normal 
forms3  of  data  modeling,  thus  preventing  the  unambiguous  representation  of  the 
information.  Finally,  the  high-cost  maintenance  of  this  solution  proves  to  be  a  major 
drawback  as  a  number  of  MIP  experimentations  have  shown.  Since  2004,  the  MIP 
decided  to  use  MEM  only  to  convey  writer-to-reader  information,  and  to  use  the  Data 
Exchange  Mechanism  to  convey  the  C2IEDM  structured  information  between  MIP- 
complaint  systems. 


3.2.2  The  Data  Exchange  Mechanism 

The  MIP  Technical  Interface  Design  Plan  [17]  details  the  DEM.  Broadly,  it  consists  of 
the  replication  of  data  between  instances  of  the  Command  and  Control  database 
(C2DB,  note  that  for  clarity  the  database  is  being  distinguished  from  the  data  model). 
Several  MIP  members,  including  the  Canadian  army,  have  an  implementation  of  the 
automated  replication  mechanism  (ARM)  specification.  The  ARM  is  built  on  a 
replication  database  that  consists  of  about  40  tables  (Figure  2).  These  tables  are  used 
to  coordinate  the  transport  of  data  from  one  C2DB  instance  to  another.  In  essence,  the 
ARM  database  identifies  nodes  in  the  C2DB  network,  protocols  between  the  nodes, 
data  contracts  between  the  nodes,  and  the  actual  data  contained  in  the  C2DB  instance. 
In  terms  of  the  data,  the  ARM  database  holds  information  on  the  data  value  and  the 


3  Normalization  is  a  design  process  that  minimizes  data  redundancy  and  anomalies  within  a  data 
structure  [18]. 
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table  and  column  where  that  data  value  resides  in  the  C2DB  instance  providing  the 
data.  Since  the  database  to  be  replicated  is  an  instantiation  of  the  C2IEDM, 
information  exchange  between  systems  constitute  semantically  complete  sets. 

Implementing  the  DEM  is  not  trivial.  However,  as  compared  to  the  MEM,  the  DEM 
constitutes  an  information  exchange  solution  better  suited  for  systems  interoperability. 
This  is  because  the  DEM  deals  specifically  with  replication  between  C2DB  instances. 
Thus,  the  DEM  is  capable  of  conveying  the  semantic  meaning  and  relationships 
present  within  the  data  contained  in  the  C2DB. 

The  ARM  provides  C2DB  to  C2DB  communication,  while  other  software  provide 
direct  links  for  placing  and  retrieving  C2DB  data.  Software  applications  developed  by 
DRDC  Valcartier,  such  as  OPERA,  provide  operational  functionality  out  of  the  C2DB. 
Software  developed  by  the  US  Naval  Undersea  Warfare  Center  (NUWC),  called  the 
Operational  Context  Exchange  Service  (OCXS,  [19]),  provides  an  extensible  markup 
language  (XML)  based  data  entry  method  to  the  C2DB.  A  schematic  of  an  OCXS 
message  object  placing  data  into  the  C2DB  is  shown  in  Figure  3. 


Network 

Connection 


Figure  2.  The  ARM  consists  of  a  database  specifically  for  managing  the  data  replication  between  two 
C2DB  instances.  The  ARM  database  consists  of  about  40  tables,  while  the  C2DB  consists 
of  about  200  tables.  Reproduced  from  [20]. 
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Message 

Object 


Client  Tier  (Application  Server)  Database  Tier 


Figure  3.  The  OCXS  uses  input  message  objects  in  XML,  to  construct  SQL  input  statements  that  are 
used  to  place  data  into  the  C2DB  (shown  here  as  C2IEDM).  Reproduced  from  [21]. 
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4.  GCCS-M  and  the  Navy 


The  background  of  the  COE,  GCCS-M  and  C2IEDM  has  been  established  in  the 
preceding  sections.  We  now  outline  the  position  of  the  Canadian  navy  with  respect  to 
these  technologies  and  developments.  Once  the  navy’s  position  is  established,  we  will 
explore  potential  development  scenarios  that  satisfy  the  requirements  of  the  CF  in  the 
future. 


4.1  The  Future  of  GCCS  in  the  Canadian  Navy 

The  Canadian  navy  has  considerable  expertise  and  developed  knowledge  regarding  the 
COE,  GCCS-M  and  supporting  databases.  The  USN  also  has  considerable  investment 
in  all  of  these  technologies.  As  well,  the  USN  has  development  plans  extending  to 
2010  to  utilize  GCCS-M  as  the  central  component  in  the  development  of  the  Common 
Underwater  Picture  (CUP)  [22].  A  US  program  supporting  anti-submarine  warfare 
(ASW)  operations  will  concentrate  on  the  development  of  decision  support  and 
collaboration  tools  for  the  specific  purpose  of  providing  a  shared  awareness  and 
understanding  of  the  underwater  scene.  GCCS-M  is  the  intended  host  of  the 
development.  The  plan  also  calls  for  the  eventual  host  being  JC2.  The  estimated 
funding  required  for  this  development  is  $57  million  USD  over  5  years. 

The  Canadian  Navy  recognises  the  continued  support  that  GCCS-M  is  obtaining  from 
their  US  counterpart.  A  recent  memorandum  from  Canadian  Vice  Admiral  R.D.  Buck 
clearly  states  the  Canadian  Navy’s  need  for  compatibility  with  US  COE  and  future 
NCES  developments.  As  stated,  “ adoption  of  any  non-NCES  approach  is 
unacceptable  to  the  [Canadian]  navy ”  [23]. 

There  are  two  primary  reasons  for  this  strong  position.  First,  a  non-NCES  approach 
would  distance  the  Canadian  navy  from  full  interoperability  with  the  US  navy. 

Second,  it  would  place  additional  resource  commitments  on  the  Canadian  navy,  to 
finance  the  necessary  systems  and  development  to  regain  interoperability  with  the 
USN.  Both  would  lead  to  reduced  capabilities  for  the  Canadian  navy. 

The  memorandum  clarifies  the  navy  position  on  the  future  Canadian  maritime 
operating  environment.  However,  the  need  for  a  joint  command  and  control  data 
model  is  also  recognized,  provided  the  support  comes  with  the  necessary  resources  for 
the  maritime  portion  and  that  it  builds  on  the  existing  initiatives  with  the  USN  [23]. 
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4.2  Data  Transfer  Pathway 


Based  on  the  above  information,  it  is  reasonable  to  expect  the  continued  use  of 
GCCS-M  in  the  Canadian  navy.  However,  the  Canadian  army  has  devoted 
considerable  resources  to  the  research  and  development  of  the  C2IEDM.  The  data 
model  and  system  that  support  the  model  have  now  entered  the  demonstration  phase. 
One  recent  demonstration  showed  data  transfer  between  national  systems  involving 
Canadian,  US  and  Portuguese  implementations  [24]. 

The  apparently  divergent  positions  of  the  USN  and  the  Canadian  army,  places  the 
Canadian  navy  in  a  middle  position.  The  navy  needs  to  explore  methods  of 
maintaining  data  flow  with  the  Canadian  army,  while  remaining  interoperable  with  the 
USN.  Thus,  we  need  to  determine  if  there  exists  a  reasonable  and  feasible  data  transfer 
pathway  between  the  GCCS-M  and  C2IEDM  systems. 

To  explore  possible  pathways,  we  should  first  consider  the  existing  GCCS-M  software 
and  its  use.  The  existing  applications,  such  as  those  that  support  data  fusion4  under 
GCCS-I3,  provide  benefit  because  they  utilize  data  available  via  existing  data 
structures.  For  example,  the  MIDB  structure  provides  data  to  the  GCCS-I3 
application,  thereby  utilizing  the  collected  intelligence  data.  The  navy  are  familiar 
with  these  applications  and  would  likely  support  a  progression  that  allows  the 
continued  use  of  such  applications. 

For  the  continued  use  of  these  applications,  one  possible  solution  is  to  incorporate  the 
C2IEDM  into  the  COE,  effectively  producing  a  C2IEDM  COE  segment.  This  would 
provide  the  entire  C2IEDM  data  source  to  all  COE  applications5.  However,  the 
applications  presently  existing  within  the  COE  would  not  be  able  to  utilize  the  data 
source  without  modification  to  the  application.  This  is  because  the  application  would 
not  be  working  in  the  same  semantic  space  as  the  C2IEDM  segment.  Alternately,  the 
C2IEDM  segment  may  include  a  mapping  application  to  exchange  data  with  an 
existing  COE  segment  (e.g.,  MIDB  or  TMS)  that  is  utilized  by  other  applications.  This 
would  effectively  provide  a  bridge  between  the  C2IEDM  and  application  segments. 
However,  the  full  semantic  data  space  offered  by  C2IEDM  would  not  be  utilized  by 
the  application,  because  only  those  data  that  could  be  stored  in  the  intermediate 
segment  would  be  available  to  the  application.  This  condition  is  known  as  semantic 
loss  [26]. 

This  type  of  mapping  application  or  bridging  has  potential  benefits  in  the  medium 
term.  The  development  would  provide  an  increased  data  sharing  capability  between 
the  Canadian  army  and  navy.  However,  the  level  of  effort  required  for  the  mapping 
may  be  considerable.  As  well,  it  should  be  recognized  that  any  resources  spent  on 


4  The  data  fusion  capabilities  in  GCCS-I3  may  be  described  as  manual  Level  1  fusion  [25].  This  means 
the  operator  is  responsible  for  associating  observations  from  external  sources  with  existing  tracks 
within  the  GCCS. 

5  Application  is  used  to  describe  one  or  more  mission-application  segments,  which  combine  to  address 
a  particular  functionality. 
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such  a  development  are  not  contributing  to  the  longer  term  USN  NCES  vision.  In  the 
NCES  future,  the  data  sources  will  be  autonomous  services  in  the  enterprise.  As  such, 
data  sources  will  not  be  linked  to  particular  applications,  but  rather  to  the  enterprise. 

In  turn,  enterprise  applications  are  available  to  utilize  the  data  services. 

To  meet  immediate  needs,  a  short-term  development  solution  is  sought  that  allows  the 
GCCS-M  and  supporting  applications  to  utilize  data  from  the  C2IEDM,  but  requires 
minimal  development  effort.  One  potential  avenue  that  satisfies  these  requirements 
involves  the  mapping  of  the  C2IEDM  structure  to  the  GCCS  messaging  structure, 
OTH-T-GOLD  (Figure  4).  This  avenue  would  allow  the  transfer  of  unit  positional 
information  from  a  C2DB  to  either  a  GCCS-M  or  GCCS-M  13  system.  This  type  of 
mapping  is  part  of  the  C2IEDM  effort  underway  in  DRDC  Valcartier.  Also,  DRDC 
Valcartier  has  produced  an  interface  between  OTH-T-GOLD  and  the  C2IEDM,  thus 
giving  access  to  Tactical  Management  System  (TMS)  data.  This  was  demonstrated  in 
the  2004  Atlantic  Littoral  Intelligence,  Surveillance  and  Reconnaissance  (ISR) 
Experiment  (ALIX)  experiment  and  will  likely  be  documented  in  the  final  report. 


4.3  Other  US  Integration  Activities 

As  the  development  of  NCES  comes  to  fruition,  the  potential  integration  of  a  data 
source  such  as  C2IEDM  becomes  more  likely.  One  could  envisage  the  C2IEDM  being 
one  of  the  many  data  services  available  on  the  NCES  (Figure  4).  In  this  case, 
applications  that  have  been  built  to  support  the  NCES  then  become  accessible  to  the 
C2IEDM  thus  allowing  data  flow  into  and  out  of  the  C2IEDM  data  source. 

The  NCES  vision  is  currently  being  explored  in  the  US  in  the  form  of  initiatives  that 
directly  contribute  to  interoperability  solutions  involving  GCCS-M.  The  extensible 
Tactical  C4I6  Framework  (XTCF)  is  one  such  US  initiative.  This  project,  established 
under  the  Office  of  Naval  Research  (ONR),  may  be  considered  a  prototype 
implementation  of  NCES. 


6  C4I  -  Command  &  Control,  Communications,  Computers  and  Intelligence 
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Figure  4.  The  upper  panel  shows  the  COE  as  a  set  of  COE-component  segments  (indicated  by 

dashed  lines).  Applications  that  operate  within  the  COE  (e.g.,  GCCS-M)  contain  mission- 
application  segments.  C2IEDM  would  be  linked  to  the  GCCS  systems  by  a  mapping  that 
utilizes  OTH-T-GOLD  messages. 

The  lower  panel  shows  NCES  as  a  broad  environment  into  which  applications  are  placed. 
Wrappers  that  allow  the  application  to  communicate  with  the  NCES  are  shown  as  blue 
dashed  lines. 


The  central  objectives  of  XTCF  are  to  establish  and  leverage  a  data  management 
framework  that  allows  the  easy  integration  and  use  of  data  sources  that  support  a 
common  operational  picture,  and  to  support  the  use  of  the  GCCS-M  communication 
and  tactical  data  exchange.  The  XTCF  vision  is  a  common  enterprise  to  which  sensor 
data,  correlation  engines,  applications  and  databases  are  connected  (Figure  5).  The 
Phase  3  software  development  plan  [28]  calls  for  the  incorporation  of  MIDB  into  the 
XTCF.  Although  the  integration  of  the  C2IEDM  is  not  currently  described  in  the 
development  plan,  there  is  no  technical  reason  why  C2IEDM  could  not  be  incorporated 
in  a  similar  way. 

The  second  US  initiative  of  relevance  to  this  investigation  is  the  Family  of 
Interoperable  Operational  Pictures  (FIOP)  [29].  The  FIOP  is  intended  to  fuse  data 
available  in  individual  systems,  into  a  common  operational  and  tactical  picture.  The 
program  has  10  focus  areas,  including  the  Situational  Awareness  Data  Interoperability 
(SADI)  and  Tactical  Data  Link  (TDL)  Integration.  The  SADI  objective  [30]  is  to 
define  a  common  data  exchange  for  situational  awareness.  The  basis  for  this  data 
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exchange  is  the  C2IEDM.  The  other  focus,  the  TDL,  intends  to  integrate  the  Joint 
Data  Network  (JDL)  with  the  GCCS  FoS.  Thus,  indirectly  the  FIOP  will  contribute  to 
the  effort  to  combine  data  from  C2IEDM  and  GCCS. 


extensible  Tactical  C4I  Framework 

Data  Translation  &  backward  Compatibility  •  Distributed  Architecture  •  Publish  &  Subscribe  •  Query  &  data  distribution 


Figure  5.  The  vision  ofXTCF.  Data  sources,  such  as  acoustic  intelligence  (ACINT),  radar 

intelligence  (RADINT),  signal  intelligence  (SIGINT)  and  other  future  sensors  provide  sensor 
data  to  the  enterprise.  The  correlation  engines  and  applications  utilize  the  sensor  data  and 
those  data  in  other  data  sources  such  as  the  MIDB,  the  electronic  intelligence  (ELINT) 
Parameter  Limits  (EPL)  and  other  databases  such  as  the  C2IEDM.  This  figure  is  based  on 
a  figure  from  [27]. 
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5.  Concluding  Remarks 


Considerable  effort  is  being  placed  on  the  design  of  architectures  and  the  development 
of  systems  that  support  interoperability.  In  many  ways,  this  effort  is  being  fuelled  by 
shrinking  resources  available  to  militaries  around  the  world,  but  also  by  common  goals 
to  protect  and  serve  the  citizens  of  the  individual  nations. 

The  commonality  of  issues  faced  by  national  militaries,  combined  with  the  collection 
of  similar  data  types,  provides  the  environment  for  collaborative  sharing  of  data  and 
information  across  national  systems  and  services.  However,  there  exists  the  continual 
need  to  rationalize  demonstrations  of  existing  technologies  with  current  operational 
procedures.  As  well,  demonstrations  must  account  for,  but  not  necessarily  integrate 
with,  planned  or  emerging  systems  that  may  impact  existing  procedures. 

In  the  Canadian  navy,  present  research  is  examining  the  general  topic  of  Network 
Enabled  Operations.  This  research  is  considering  numerous  subtopics  including  the 
integration  of  data  from  multiple  sources  (e.g.,  either  sensors  or,  nonorganic  tactical  or 
combat  systems). 

The  Canadian  military  research  community  is  moving  forward  with  these 
investigations,  while  recognizing  both  short  and  long  term  client  needs.  Part  of  the 
requirements  for  the  Canadian  navy  is  interoperability  with  the  USN  and  at  least  a  data 
sharing  capacity  with  other  services  of  the  Canadian  Forces. 

These  requirements  do  result  in  research  and  development  issues.  The  issues  arise 
because  the  USN  is  firmly  committed  to  GCCS-M  and  JC2.  Alternately,  the  Canadian 
army  is  developing  systems  in  support  of  the  C2IEDM. 

This  report  has  outlined  an  integration  path  for  the  Canadian  navy.  The  path  provides 
the  continued  use  of  GCCS-M  and  future  JC2,  while  establishing  a  data  sharing 
capacity  with  the  army  C2IEDM.  The  integration  is  possible  due  in  part  because 
GCCS  and  C2IEDM  are  compatible  systems.  Over  the  short  term,  the  C2IEDM  could 
be  mapped  to  the  OTH-T-GOLD  structure,  thus  providing  a  data  stream  from  the  army 
systems  to  GCCS-M.  In  the  longer  term,  the  C2IEDM  is  envisaged  as  a  data  source 
within  the  NCES. 
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List  of 

symbols/abbreviations/acronyms/initialisms 


ACINT 

Acoustic  Intelligence 

Adat-P3 

Allied  Data  Publication  3 

ALIX 

Atlantic  Littoral  ISR  Experiment 

API 

Application  Programming  Interface 

ARM 

Automated  Replication  Mechanism 

ASW 

Anti-Submarine  Warfare 

ATCCIS 

Army  Tactical  Command  and  Control  Information  System 

C2DB 

Command  and  Control  Database 

C2IEDM 

Command  and  Control  Information  Exchange  Data  Model 

C2IS 

Command  and  Control  Information  Systems 

C4I 

Command  &  Control,  Communications,  Computers  and 
Intelligence 

CES 

Core  Enterprise  Services 

CF 

Canadian  Forces 

COE 

Common  Operating  Environment 

COI 

Community-of-Interest 

COP 

Common  Operating  Picture 

CUP 

Common  Underwater  Picture 

DB 

Database 

DEM 

Data  Exchange  Mechanism 

DII 

Defense  Information  Infrastructure 

DISA 

Defense  Information  Systems  Agency 

DRDC  Atlantic  TM  2004-197 


23 


DND 

Department  of  National  Defence  (Canada) 

DoD 

Department  of  Defense  (US) 

DRDC 

Defence  Research  and  Development  Canada 

DRP 

Document  Review  Panel 

ELINT 

Electronic  Intelligence 

EPL 

ELINT  Parameter  Limits 

ESM 

Enterprise  Service  Management 

ESMTP 

Extended  Simple  Mail  Transfer  Protocol 

FIOP 

Family  of  Interoperable  Operational  Pictures 

FoS 

Family  of  Systems 

GCCS 

Global  Command  and  Control  System 

GCCS-A 

GCCS  Army 

GCCS-I3 

GCCS  -  Integrated  Imagery  and  Intelligence 

GCCS-J 

GCCS  -  Joint 

GCCS-M 

GCCS  -  Maritime 

GCCS-T 

GCCS  -  Top  Secret 

GIG 

Global  Information  Grid 

I&RTS 

Integration  and  Runtime  Specification 

ICCRTS 

International  Command  and  Control  Research  and  Technology 
Symposium 

IR 

Information  Requirement 

IEM 

Information  Exchange  Mechanism 

IER 

Information  Exchange  Requirement 

ISR 

Intelligence,  Surveillance  and  Reconnaissance 
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ISTAR 

JC2 

JC3IEDM 

JDL 

LC2IEDM 

LFC2IS 

MEM 

MIDB 

MIP 

MIST 

MTF 

MTIDP 

NATO 

NCES 

NCW 

NEOps 

NUWC 

OCXS 

ONR 

OTH-T-GOLD 

RADINT 

SADI 

SIGINT 


Intelligence,  Surveillance,  Target  Acquisition  and 
Reconnaissance 

Joint  Command  and  Control 

Joint  Consultation  Command  and  Control  Information 
Exchange  Data  Model 

Joint  Data  Network 

Land  Command  and  Control  Information  Exchange  Data 
Model 

Land  Forces  Command  and  Control  Information  System 

Message  Exchange  Mechanism 

Modernized  Integrated  Database 

Multilateral  Interoperability  Programme 

Maritime  Information  Sharing  Technology 

Message  Text  Format 

MIP  Technical  Interface  Design  Plan 

North  Atlantic  Treaty  Organization 

Net  Centric  Enterprise  Services 

Net  Centric  Warfare 

Network  Enabled  Operations 

Naval  Undersea  Warfare  Center 

Operational  Context  Exchange  Service 

Office  of  Naval  Research 

Over-The-Horizon  Targeting  Gold 

Radar  Intelligence 

Situational  Awareness  Data  Interoperability 
Signal  Intelligence 
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SQL 

TD 

TDL 

TMS 

US 

USD 

USMTF 

USN 

XML 

XSLT 

XTCF 


Structured  Query  Language 

Technology  Demonstration 

Tactical  Data  Link 

Tactical  Management  System 

Unites  States 

Unites  States  Dollars 

US  Message  Text  Format 

United  States  Navy 

extensible  Markup  Language 

extensible  Stylesheet  Language  Transformation 

extensible  Tactical  C4I  Framework 
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